Safety requirements for automotive electronics are being standardized in a number of application segments. An example of application segments includes chassis applications, which United States government legislation requires to be standardized for each new vehicle from 2012. A further example is electric power steering.
Automotive braking applications and steering applications also both require sophisticated electronic solutions that allow switching to a safe state in case a malfunction is detected. Accordingly, awareness of safety issues, for example by a system-on-chip (SoC), is of increasing importance in today's vehicular applications, although the usage of such devices is not limited to such applications. However, the safety level required differs from application to application. For example, some applications may require Safety Integrity Level (SIL) 3, whilst other applications may require SIL 2. Safety Integrity Levels are defined as a relative level of risk-reduction provided by a safety function, or as a specific target level for risk reduction. Four SIL levels are defined by the International Standard IEC 61508, ranging from SIL 4, being the most dependable, to SIL 1, being the least dependable.
Different levels of safety may require varying amounts of redundancy of building blocks and connectivity within the SoC. As a result of this, known SoCs are designed with a specific SIL in mind. However, the need to develop multiple SoC architectures to support multiple SILs makes the development of safety aware devices complex and costly.
In order to demonstrate that a device is applicable to a particular SIL level, it is necessary to demonstrate that the device is capable of detecting a defined proportion of faults, depending on the particular SIL level—50%, 60%, 90%, or 99%, for example. As will be appreciated, for some devices, such as processor devices comprising complex cores, the only feasible way of demonstrating that the device is capable of detecting a defined proportion of faults is to use a fault simulation tool, which simulates faults on the device using gate-level code for the device under control of the fault simulator. It is known that, in some instances, the fault simulation tool may inject one or more faults into the device, and thereafter identify those faults that may be detected by the device and those that may not. In this manner, an SIL level of the device may be demonstrated based on the results from the fault simulator.
In addition to the need for demonstrating SIL levels for devices, sophisticated core and device self-test applications are becoming a key technical requirement by vehicle manufacturers who employ such semiconductor devices.
Self test applications and fault simulation tests, such as those that may used to demonstrate the SIL level of a device, are typically required to be executed concurrently with the normal functionality of the device under test, in order to provide realistic results. A problem with performing such tests is that, in order to achieve a suitably accurate fault simulation test (e.g. >90% fault coverage), such testing typically requires extensive test code sizes and lengthy test code execution times. Unfortunately, the use of extensive test code sizes and lengthy test code execution times makes the implementation and performing of such tests impractical, if not unfeasible.
It is known that techniques for speeding up fault simulation significantly affect the reliability of the tests. For example, omitting hardware and software modules of the device from the test run may result in propagation of faults and/or mask properties that are not being reliably tested. Furthermore, limiting the injection of faults within a specific module for a given test may cause faults in other modules, which will not be counted since they do not relate to the module under test, causing significantly more tests to be implemented, or the declared achieved coverage underestimated.
Another known technique for speeding up fault simulation, known as multi-strobing, comprises checking, or ‘strobing’, locations within a device more frequently after the injection of a fault than would be performed by the test code of the device under normal operating conditions. Although this enables fault detection by the test code of the device to be identified more quickly, and thus enabling fault simulation to be accelerated, because strobing is performed more frequently than would be the case under normal conditions, the results are unrealistic.
Consequently, such known techniques for speeding up fault simulation are unacceptable, particularly when needing to demonstrate an SIL level of a device, or for self-testing processes within safety applications, due to the consequent effect on the reliability of the tests. In particular, in order for such fault simulation tests for safety applications to be considered sufficiently accurate and reliable, they should perform:                simulation of all the real and complete part(s) of the device that are within the scope of fault detection and propagation;        (ii) simulation of all the software that comprises core/device initialisation, test code, and propagation of detected faults to predefined place(s) within the device; and        (iii) comparison of the results during simulation and during execution of the test code on the real device in the same way and in the same manner.        
However, in order to make such fault simulation tests both commercially feasible and practical, test code sizes and test code execution times are required to be significantly reduced relative to those currently used or required for current safety applications.